Legend

Core Concepts

Legend has a small vocabulary. Once you understand these four ideas, the rest of the product follows naturally. This page goes a level deeper than the Introduction so you can model your own organization with confidence.

Agents

Agents are the people and teams in your organization. A person can belong to one or more teams, and a team can own things on its own. Agents are who you turn to when you need to know who is responsible for something.

People and teams

  • A person is an individual: an employee, a contractor, or a manager.
  • A team is a group that works together and often owns things collectively, such as Engineering, Sales, Operations, or HR.
  • Model teams the way your organization actually works rather than forcing a strict hierarchy, since ownership tends to sit with whoever does the work.

Why represent both

Assigning ownership to a team keeps the map accurate when individuals change roles, because the team persists. Assigning ownership to a person is useful when a single individual is the clear point of contact. Legend supports both, so you can match reality instead of forcing everything to one style.

Landmarks

Landmarks are the things worth finding. If it is something people search for, ask about, or depend on, it belongs on the map as a Landmark. Landmarks carry a type, an owner, and metadata that helps people find and understand them.

Common Landmark types

  • Services: software and tools you run or rely on, built in house or provided by a vendor.
  • Resources and assets: files, drives, databases, and other materials teams reference.
  • Processes: workflows and procedures such as onboarding, incident response, or vendor approval.
  • Documentation: guides, runbooks, policies, and references that explain how things work.
  • Projects and events: initiatives, migrations, launches, and reviews when you want them on the map.

The exact set of types available in your instance depends on your version. Use the type that best matches what the Landmark represents; you can always adjust it later.

Relationships

Relationships are the lines between entities. They record who owns what and how Landmarks connect to each other. Relationships turn a list of entities into a navigable structure and make questions like "who owns this?" and "what depends on this?" answerable.

Kinds of relationship

  • Ownership connects an Agent to the Landmarks it is responsible for.
  • Dependency connects a Landmark to the other Landmarks it relies on, such as a process that uses a service.
  • Documentation links connect a Landmark to the documents that describe it.
  • Membership connects people to the teams they belong to.

Because relationships are recorded directly rather than implied, you can traverse them in either direction. From a service you can find its owner, and from an owner you can find every service they are responsible for.

The map

The map is everything together: your Agents, your Landmarks, and the relationships between them. It is the single place your team navigates to find owners, follow dependencies, and reach the documentation that explains how things work.

Screenshot: the map view zoomed in on a single service, with lines running to its owning team, a dependent process, and an attached runbook.

A worked example

Say you operate a Billing API. As a set of connected entities it looks like this:

  • Billing API is a Landmark of type Service.
  • It is owned by the Platform Engineering team, an Agent.
  • The monthly invoicing process, a Landmark of type Process, depends on it.
  • A runbook, a Landmark of type Documentation, is linked to it.

With those four entities and their relationships in place, a new hire can search "billing", land on the service, and immediately see who owns it, what depends on it, and where to read more. That is the whole point of the map.