The map shows four systems between the Pathfinder and Home. The line is clean. Every node has a name. Nothing on the screen looks uncertain.
At the second Wormhole, the expected connection is gone.
The map was not useless. It was a report that outlived one of its edges. Navigation failed only if the pilot mistook that report for a permanent road.
In Anoikis, mapping does not copy a fixed network. It assembles a temporary argument from systems, Wormholes, Bookmarks, observations and time. Navigation is the work of testing that argument one connection at a time.
The map gives the Chain a shape. The Pathfinder keeps that shape honest.
Shape of Passage
A useful Wormhole map begins with two kinds of thing: systems and the connections between them.
The systems are places. They persist beyond a particular visit. The connections are opportunities for passage. They open between places, carry traffic and eventually collapse.
This difference explains the common node-and-line shape used by current mapping tools. A node can hold the System Identifier, Class, Type, Effect and other system context. A line can hold the Wormhole that presently relates one node to another.
The line is not a measured distance. Two systems drawn next to one another may be one Wormhole apart, but the spacing on the screen says nothing about the physical length of the transit. Its topology shows which passage leads to which place.
That abstraction is powerful because it matches the decision. A Pathfinder usually needs to know how many current connections must survive, which ones have poor condition and where an alternative branch begins. Decorative geography would add little.
The same abstraction becomes dangerous when the clean shape hides weak evidence. A line entered from an old report can look identical to a line crossed moments ago. The map must carry Source and freshness, or its geometry will appear more certain than the work beneath it.
Map the relationship. Preserve the reason for believing it still exists.
Nodes and Edges
Each node should identify a system without asking a Chain alias to replace its real identity.
A local name such as Home, A1 or East Branch can make communication
faster. It should remain an alias attached to the current map. Identity that
other pilots and data sources can recognise comes from the System Identifier
and current proper name, when one exists.
Each edge should represent one Wormhole connection. It needs its own endpoint information, observed condition and relationship to the Bookmarks used on both sides.
This separation prevents several common distortions:
- a system is not deleted merely because one connection to it collapses;
- two Wormholes between relevant places are not compressed into one vague route;
- the state of a Wormhole is not attached to the destination system as though it described every entrance; and
- a Chain alias can be changed without rewriting the underlying system.
The model remains simple enough to read under pressure. The node answers where. The edge answers through what current connection. The endpoint Bookmark answers from which position in this system.
Navigation requires all three. A system name without an edge does not supply a route. An edge without a Bookmark may describe a route the current pilot cannot warp to. A Bookmark without the map may reach a Wormhole without revealing which branch follows.
Together they turn scattered records into a path.
Endpoints Matter
Chapter 7 preserved two endpoints for every traversed connection. Mapping gives those positions one relationship without merging them.
A sound edge points to both endpoint Bookmarks or to the naming information needed to select them. If only one side is preserved, the map describes a relationship that can be entered from one direction but may not be recoverable from the other.
Direction also changes language. A Bookmark marked RETURN in system B may
refer to system A. The corresponding Bookmark in system A is not another
return unless the operation defines Home on system B’s side. Labels describe
use from the system in which they exist.
This becomes especially important when branches meet. One pilot may enter a
system through one Wormhole and leave through another. Calling both the exit
stores the route in memory rather than in the records.
The map should allow a receiving pilot to trace a sentence without guessing:
From this system, use this endpoint Bookmark, cross this connection and expect to arrive in that system.
Every hop in a route is that sentence repeated under new conditions.
State the Edge
A connection record should contain only what can be defended, but enough to support a decision.
At minimum, preserve:
- the systems currently related;
- the local endpoint identifiers or Bookmark references;
- the observed Reliable Lifetime and mass condition;
- the maximum ship-size indication when it affects the operation;
- the Source and Timestamp of those observations; and
- whether the relationship was crossed, directly observed or only reported.
Not all fields share one freshness. The systems related by a crossed Wormhole are strongly derived from the transit. The mass condition may have changed with that transit. A destination clue read before crossing may remain useful, but the actual arrival now supplies stronger evidence of the destination.
Update the fields that changed without refreshing the ones that were not observed. Editing a map node at 14:20 must not make a Wormhole condition last seen at 13:50 appear twenty minutes newer.
Broad last updated labels can mislead here. Such labels describe the record,
not necessarily each claim inside it.
A good Shared Map keeps those fields separate. It can show that the edge and its lifetime were observed now, while the mass state came from an older report and the far-side Bookmark remains unconfirmed.
Honest partial information is navigable. False uniform freshness is not.
Routes Are Conditional
A route is a sequence of edges that the map currently believes can be used.
The word currently carries most of the risk.
Every additional Wormhole introduces another condition that may fail. Its Reliable Lifetime can advance. Its mass condition can worsen. It can reject the ship because of size or Polarization. Another pilot can alter it between the scout’s report and the Fleet’s arrival.
The shortest route therefore need not be the best route. A longer branch with healthier, fresher connections may support a larger commitment. A one-hop exit near collapse may suit a disposable scout and be unacceptable for repeated industrial traffic.
Route planning should compare at least:
- number of Wormhole transits;
- condition and age of each connection report;
- ship-size and mass requirements;
- known traffic or threats;
- Polarization history of the pilot; and
- alternatives available if one edge fails.
These factors do not produce a universal score. They expose where the plan is fragile.
When communicating a route, include its limiting edge. Four hops to Home is a shape. Four hops to Home, with the second connection Expired and no mapped alternative is a decision.
The map should help the pilot see both.
Freshness Has Layers
Time does not act upon every map element in the same way.
A system’s Class or special Type is relatively stable reference data. A Wormhole’s Reliable Lifetime and mass condition are temporary observations. A ship seen on Directional Scanner may matter for seconds. A Bookmark can retain coordinates after the object it described has gone.
One age marker for the whole node cannot represent those layers honestly.
Attach freshness to the changing claim:
- when was this connection last observed?
- when was its condition read?
- when was the endpoint Bookmark verified?
- when was the system last scanned for Signatures?
- when was the threat report produced?
This does not require filling the map with timestamps until it becomes unreadable. The interface can show compact age indicators while retaining the underlying times in details. What matters is that a recent edit cannot launder old information into looking new.
Stable data also needs a Source even when it does not need continual observation. A current SDE classification and a pilot’s visual guess should not acquire the same authority merely because they display the same Class.
Freshness answers when. Source answers from where. The map needs both when the claim can change or be wrong.
Preserve Unknowns
A map invites completion. Empty fields look unfinished. Unconnected nodes look untidy. That visual pressure encourages guesses.
Resist it.
Record an unresolved Signature at the level the scan supports. Do not convert an indicated Wormhole destination into a confirmed system. Let the map show when an endpoint Bookmark has not been tested.
Unknown is not the same as absent.
An unscanned branch may exist. An old edge may already be gone. A missing mass report does not mean full mass. No threat marker does not mean no threat.
Useful map symbols distinguish at least three cases:
- confirmed information;
- Reported or incomplete information; and
- no information.
The exact colours or icons depend on the tool. Their definitions must be shared by the people using the map. A yellow line is not helpful if one pilot reads it as caution and another as unverified.
Unknowns also guide work. They show the next scout where a fresh transit, condition check or Signature pass will improve the route most.
A complete-looking map can hide uncertainty. An honest map makes uncertainty actionable.
Reconcile the Picture
Two pilots can return different reports without either acting carelessly.
One crossed the Wormhole ten minutes ago. Another now finds no object at the Bookmark. A third still sees the edge in a mapping tool because no one has retired it. These statements describe different times and interfaces.
Do not force them into agreement by choosing the most convenient one.
First, preserve the observations and their Timestamps. Then ask which event could relate them. The Wormhole may have collapsed. The wrong Bookmark may have been selected. A folder may be unavailable. The map may contain two connections that were compressed into one label.
Reconciliation is the process of finding that missing relationship.
When evidence shows that an edge is gone, retire the connection rather than deleting the history without explanation. The old record can show why a route or Bookmark still exists and prevent another pilot from rebuilding the same mistake.
When the evidence is incomplete, mark the edge unverified and direct the next check. A map that says not found from this Bookmark at 14:20 is more useful than one that silently removes the line while another pilot may still be in the far system.
Shared truth is not produced by making every screen match. It is produced by explaining why they differ.
Tools Extend Memory
Current Wormhole mapping tools can share systems, connections, Signatures, notes and route information across a group. Some can notice character transits, reconcile pasted Probe Scanner results or estimate connection state from user-entered traffic.
These features reduce clerical work. They do not remove the observer.
Automatically adding a node can show that a tracked character changed systems. It may still require the pilot to identify which Wormhole was used. An estimated mass remainder depends on the transits recorded and the mass assumptions applied. A coloured edge depends on someone entering the correct condition.
The more smoothly a tool updates, the easier it is to forget which parts came from the client and which parts were inferred.
Treat automation as another Source. Know what event it observes, what it derives and what it cannot see. If a tool tracks position through external data, understand that delayed or ambiguous events may produce the wrong connection. Current community mapping documentation explicitly warns that some non-Wormhole movements can be misinterpreted.
No specific mapper is required by this book. The operational standard survives the interface: systems and connections remain distinct, changing claims retain age and Source, and a pilot confirms the next edge before depending upon it.
The tool should make disciplined work easier to see, not make discipline invisible.
Navigate by Confirmation
Following a Shared Map is not the passive part of Pathfinder work. Every hop tests the route.
Before warping, match the current system, intended edge and endpoint Bookmark. On Grid, confirm that the Wormhole object exists and read the state relevant to the ship. After transit, confirm the destination and preserve the far endpoint. Then update the map with what the crossing actually established.
This rhythm keeps errors local.
A system check can catch the wrong Bookmark before warp. A Grid check can stop the transit when the Wormhole state is worse than Reported. When the destination differs from the mapped node, the arrival check can prevent the false edge from spreading deeper into the Chain.
Speed comes from making each confirmation small and familiar, not from removing it.
The pilot should also know which Observation would cause the route to stop. An Expired connection, unexpected ship-size restriction, missing endpoint or unexplained destination mismatch may require reassessment. The threshold depends on the commitment, but it should exist before the surprise.
A map offers the next expected relationship. Navigation confirms whether that relationship still deserves a ship.
Recover From Drift
Sooner or later, the Chain changes around a pilot.
The mapping response comes before route recovery. Preserve the discrepancy: confirm the current system, identify the expected edge and record when it was last known to work. Retire it only when the evidence supports collapse; until then, mark it Unverified and direct the next check.
A replacement Wormhole is a new edge even when it reaches a familiar system. It needs new endpoints, Observations and time. Reusing the old line would make the map look repaired while hiding what changed.
Chapter 15 handles the larger problem of getting Home after an edge fails. Here the standard is narrower: let the Shared Map admit drift quickly enough that recovery can begin from an honest picture.
Close the Loop
A Pathfinder’s map work is complete only when another decision can safely use it.
That requires more than drawing the new edge. The endpoint Bookmarks must exist. The destination must be confirmed at the level reported. Changing state must carry a Timestamp. Important Unknowns must remain visible. The group must know whether the route is ready, provisional or already degrading.
A concise handoff can state:
- what changed in the Chain;
- which connection was personally crossed;
- which endpoint Bookmarks are usable;
- which state observations are fresh;
- what remains Reported or Unknown; and
- what condition should stop the next movement.
The handoff does not need to narrate the entire scanning session. It needs to preserve the supports of the route.
That distinction separates a private map from shared navigation. A private map helps its author remember. Another pilot can decide from a Shared Map without borrowing the author’s unspoken assumptions.
When the next pilot confirms a hop, the field sequence begins again: Observe → Record → Understand → Evaluate → Decide → Act → Observe again.
The Chain is never finished. It only needs to be current enough for the commitment being made.
Field Principle
A living map models systems connected by temporary doors. Its lines are claims, not roads.
Relate every edge to usable endpoint Bookmarks. Keep Source, freshness and Unknowns visible. Navigate by confirming the next connection, not by trusting the cleanliness of the line.