Creating Landmarks

Landmarks are the destinations on your map. This page walks through creating a Landmark end to end: choosing a type, setting an owner, filling in metadata, and connecting it to the rest of the map. The workflow is the same for every type, so once you have added one you can add any of them.

The basic procedure

  1. Open the Landmarks view and choose the option to create a new Landmark.
  2. Give the Landmark a clear name that people would actually search for.
  3. Choose the type that best matches what it represents, such as Service, Resource, Process, or Documentation.
  4. Set the owning Agent so the map records who is responsible for it.
  5. Add a short description that explains what it is and why it matters.
  6. Save the Landmark. It is now searchable and ready to connect to other entities.

Screenshot: the Landmark editor with the Owner field highlighted, showing a service assigned to the Platform Engineering team.

Choosing a type

The type shapes how a Landmark reads on the map and how people expect to use it. Pick the closest match:

Services

Services are the software and tools your organization runs or relies on, whether built in house or provided by a vendor. Recording services with their owners makes it clear who to contact and what depends on them. Good candidates: internal APIs, databases, SaaS tools, and shared platforms.

Assets and resources

Assets and resources are the files, drives, databases, and other materials your teams reference. Adding them as Landmarks means people can find the source of truth instead of guessing which copy is current. Point the Landmark at the canonical location rather than a personal copy.

Documents

Documents are the guides, runbooks, and references that explain how things work. Create the document Landmark, then link it to the Landmark it describes so the explanation sits next to the thing it explains.

Processes

Processes are the workflows and procedures your organization follows, such as onboarding a new hire or handling an incident. Mapping a process to its owner and to the systems it touches turns tribal knowledge into something anyone can look up.

Ownership and metadata

A Landmark is far more useful with an owner and a little metadata than without. When you create one, aim to fill in at least these:

  • Owner: the person or team responsible, so "who do I ask?" is always answerable.
  • Description: one or two sentences a newcomer could understand.
  • Type: the closest match, so the Landmark behaves as people expect.
  • Tags or metadata your instance supports, which make filtering and grouping easier later.

Connecting the Landmark

A Landmark on its own is just an entry. Its value comes from the relationships around it.

  1. Link the Landmark to its owning Agent if you have not already.
  2. Link it to the Landmarks it depends on, for example a process to the services it uses.
  3. Attach any documentation that describes it.
  4. Save, then search for the Landmark and follow its relationships to confirm the connections read correctly.

A quick example

Adding a Billing API as a service looks like this end to end: create the Landmark, set its type to Service, set the owner to Platform Engineering, describe it in a sentence, then link the invoicing process that depends on it and the runbook that documents it. A newcomer can now find all of that from a single search.