Bookmark Discipline

The emergency is small enough to feel embarrassing. The system contains three Bookmarks named Exit. Two are old. One belongs to another branch. The Pathfinder has seconds to choose which mark still leads towards Home.

All three positions may have been saved correctly.

The failure lies in what they no longer communicate.

A Bookmark is one of the simplest objects in the Pathfinder’s work. It preserves a position and makes that position usable later. Yet a position without clear purpose, ownership or age can turn exact coordinates into a poor decision.

Bookmark Discipline begins with a modest idea: save the right place, then make its meaning survive the moment in which it was obvious.

Position With Meaning

The client can preserve coordinates far more accurately than a pilot can remember them. That does not make the record self-explanatory.

A Bookmark answers where? Its label, folder, creation data, expiry and relationship to other records help answer what is this position for? Beyond the Bookmark, the Shared Map shows how that position participates in the current route.

Those answers should support one another without being mistaken for the same thing.

The Bookmark does not know that a Wormhole has collapsed. It continues to point at the saved position. It does not know that a route has become unsafe, that a label uses an abandoned naming scheme or that the person opening the folder understands the local alias.

That meaning is editorial work performed in the field. The Pathfinder selects what deserves preservation, names its function and removes or expires it when the function no longer exists.

More Bookmarks do not automatically produce better navigation. A short, maintained set can carry more usable knowledge than a crowded folder of exact but unexplained positions.

The standard is not whether a location was saved. It is whether the intended pilot can identify, access and use the correct location when the context is no longer fresh.

Object or Coordinate

The current location system can preserve either an object or a coordinate. The distinction affects what the Bookmark means.

An object Bookmark is created from something the client can identify, such as the Wormhole on the Grid. It preserves the position of that object when saved. A coordinate Bookmark preserves the ship’s position when the location is submitted, including a position created while the ship is moving or in warp.

Both are useful. They answer different purposes.

For a return connection, the Wormhole itself is normally the object that matters. Saving the Wormhole makes the record about the door. Saving the ship’s nearby coordinate makes the record about where the ship happened to be. The two positions may be close enough to look related and still produce different arrivals or tactical consequences.

The same distinction separates a resolved scan result from the object found after warping to it. A Bookmark created from the result preserves the scan-derived destination. A Bookmark created from the Wormhole on Grid preserves the door itself. Do not silently promote one into the other merely because both brought the Pathfinder to the same Grid.

Coordinates are not inferior. A perch, observation point or mid-warp location exists precisely because the pilot wants a position apart from the object. Discipline means naming that purpose honestly.

Before saving, decide whether the record is meant to locate the object or the ship.

Save the Door

Every traversed Wormhole needs a usable Bookmark on each side.

The reason follows from the connection model. The two ends occupy different systems and different coordinates. A record of the departure end cannot bring the ship to the arrival end. Although a Shared Map may relate the systems, it cannot create an in-game warp destination that was never saved.

On first arrival, the return end carries the clearest meaning it will ever have: it is the door just used. Save the Wormhole object before warping away. Do the same work on the other side when that endpoint is first encountered.

This creates two Bookmarks for one connection, not a duplicate.

Each endpoint should be identifiable from within its own system. The label must not require the pilot to stand on the other side before understanding it. If the group uses local Chain names, the name should indicate the destination or direction from the side on which the Bookmark exists.

A useful check is to imagine the connection closed and the map unavailable. Would the label still reveal which saved point was intended to lead Home, move outward or reach a named neighbour? If not, too much meaning lives outside the Bookmark.

Do not overload the label with every fact known about the Wormhole. Save the door first. Relate it to the map. Put changing state where it can be maintained.

Name the Function

Labels are read under different conditions from those in which they are written. A label may be created in a quiet system and searched for later while the Grid is contested.

The first element should therefore answer the most urgent operational question. Is this the return, an outward connection, an observation point or a location not yet verified?

A simple label grammar can be built from four fields:

FUNCTION | DESTINATION | LOCAL ID | QUALIFIER

The fields are a model, not a universal corporation rule. A group may choose different separators, abbreviations or aliases. The order matters more than the typography.

• FUNCTION tells why a pilot would use the position.
• DESTINATION relates the Bookmark to the Chain.
• LOCAL ID ties it to the visible identifier on this side when useful.
• QUALIFIER carries only the short-lived warning needed at selection time.

For example, a homeward Wormhole Bookmark might put RETURN before a Chain alias and local Signature identifier. A newly found endpoint whose destination is not confirmed should say UNVERIFIED rather than borrowing the most likely answer.

Avoid names that depend on the creator’s private perspective. My exit, next hole and the new one decay as soon as another pilot reads them or a second connection appears.

The best label is not the most complete sentence. It is the shortest wording that preserves the decision-relevant distinction.

Identity and State

A Wormhole’s identity and its present condition age at different rates.

The endpoint position and local identifier help distinguish the object. Its destination relationship gives it a place in the Chain. Reliable Lifetime and mass condition describe a state observed at a particular time.

Combining all of these into one label can be convenient. It can also turn the label into a stale report.

If EOL remains in a Bookmark after the connection has been replaced, the old warning may attach itself to the wrong door. If FRESH remains after hours of traffic, the label becomes an assurance no one actually observed. A label that names only the state may become meaningless when the state changes.

Use the Bookmark to preserve identity and immediate function. Use the Shared Map or accompanying note to preserve state with a Source and Timestamp. If the workflow copies a critical warning into the label, treat that text as another record that must be updated or retired.

This is not an argument against visible warnings. It is an argument against timeless warnings.

The distinction makes correction easier. A pilot can update the condition of a known endpoint without inventing a new identity. The group can retire the connection without pretending the systems on either side vanished.

Name what the Bookmark is. Timestamp what the Wormhole was observed to be.

Personal or Shared

Personal and Shared Locations solve different coordination problems.

A personal Bookmark is controlled by the individual pilot. It can preserve an emergency return even when a group folder is unavailable or wrongly configured. A Shared Location allows authorised pilots to use a common position and reduces the need to reproduce the same work separately.

Neither should be assumed to substitute for the other in every operation.

A personal copy can protect the scout from a permission error, but it does not help a following Fleet unless the location is also shared through an agreed method. A Shared Location can support the group, but access depends on the folder, Access Lists and its current availability.

The operational question is therefore twofold:

Can I use this position? Can the people who depend on my report use it?

Answer both before announcing the route as ready.

Redundancy should be deliberate. Saving an essential return personally and in the correct shared folder may be justified. Copying every temporary location into every available folder produces clutter and creates several records that can age differently.

The group needs a declared source of operational truth. If the Shared Map carries state and the shared Bookmark folder carries warpable positions, say so. Personal copies then remain recovery aids rather than competing authorities.

Access Takes Time

A Shared Location is not necessarily usable by everyone at the instant it is created.

The current system places Shared Locations in folders controlled by Access Lists. Pilots must have the appropriate access and the folder must be connected and available. Newly added Shared Locations also have a short delay before they become usable as warp destinations; the current documented delay is two minutes.

This changes the meaning of shared.

It may mean that the record has been placed in a shared folder. It does not yet prove that a specific pilot can see it, that the folder is online for that pilot or that the new Bookmark has become warpable.

During ordinary work, the delay is easy to absorb. During an extraction or Fleet movement, it can become the difference between information and capability. A scout who reports Bookmark shared should distinguish creation from confirmed usability.

The receiving pilot can close the loop with a precise response: the folder is connected, the location is visible, and the warp command is available. That confirmation is stronger than assuming that no error message means the handoff succeeded.

Permissions can also change. A Bookmark may remain correct while becoming unavailable to the people who once used it. Diagnose the layers separately: position, label, folder, access and readiness.

The location can be true while the handoff has failed.

Time Belongs Inside

Every temporary Bookmark needs a retirement expectation.

The location system can attach an automatic expiry to a saved position. This is useful for Wormhole endpoints and short-lived field marks because the objects they describe may disappear while the coordinates remain.

Expiry is not proof of validity until that time. It is only a limit on how long the record will be retained automatically.

A Wormhole can collapse well before its Bookmark expires. A long-lived tactical position may remain useful after a temporary expiry would remove it. The correct duration follows from purpose, not convenience.

Treat creation time and expiry as part of the Bookmark’s meaning. When a pilot sees an old position with no living connection in the Shared Map, age should encourage verification rather than trust. When a critical return point has a near expiry, the group should know whether the position will disappear during the operation.

Manual clean-up remains necessary. Remove or retire Bookmarks whose objects no longer serve the stated function. If evidence is incomplete, mark the record unverified instead of deleting the only clue another pilot may need.

Time discipline prevents two opposite errors: keeping every coordinate until the folder becomes unreadable, and deleting uncertainty before the group has resolved it.

A temporary route deserves a temporary record with a visible age.

Keep Labels Short

Long labels often begin as an attempt to be helpful. They end by hiding the first distinction the pilot needs to see.

The Locations window already carries structured information such as system, creation time, expiry and creator. Repeating all of it inside the label spends attention without adding meaning. Changing context belongs in Shared Map fields for destination class, connection state, notes and Source.

Use the label for selection.

That usually means a stable function, a destination reference and a local identifier. Add a warning only when it changes whether the position should be used now. Move explanations into notes or the map.

Abbreviation is helpful only when the intended readers share it. A private three-letter code saves space for its author and creates delay for everyone else. Define the group’s grammar before relying on it in a field handoff.

Sorting also matters. If labels begin with inconsistent decoration, personal names or prose, related Bookmarks may scatter through the list. A consistent function-first pattern lets the eye find returns, outward connections and unverified positions as groups.

The measure of a naming scheme is not how clever it looks in an example. It is how quickly a tired pilot can reject the wrong Bookmark.

Short labels carry more when the surrounding records do their own work.

Verify the Record

Creation is an action. Verification is an Observation.

After saving an important Bookmark, find it in the intended folder. Confirm the label, endpoint, expiry and availability. If it was shared, confirm that a second pilot can use it when the operation depends upon that handoff.

When practical, verify the Bookmark from a position that reveals mistakes without creating unnecessary risk. The purpose is not to perform ceremonial test warps. The check catches predictable failures: the wrong folder, a coordinate saved instead of the object, a duplicated label or a Shared Location still unavailable.

Reverification belongs to later use as well. Before committing an expensive ship to an old Bookmark, compare it with the current Grid, Probe Scanner and Shared Map. The position may remain while the Wormhole does not.

If the records disagree, preserve the disagreement long enough to diagnose it. Do not rename the Bookmark merely to make it match the map. Determine whether the position, the map relation or the current Observation is wrong.

An exact coordinate can be perfectly stored and operationally obsolete. Verification asks whether the purpose still exists.

Field Principle

A Bookmark preserves a position. Discipline preserves what that position means.

Save both ends of every traversed connection. Name function before detail. Separate identity from changing state, and confirm that the intended pilot can actually use what has been shared.