Confirmed vs inferred mappings

Not every mapping carries the same weight. Forest separates mappings it has suggested from mappings you have verified, because the difference changes how much you should trust the resulting picture.

An inferred mapping is a starting point. It comes from the catalog and reflects what a product is generally capable of supporting. Inferred mappings save you from building the Map from scratch, but they describe the product in the abstract, not your deployment.

A confirmed mapping reflects reality. When you confirm a mapping, you are stating that this tool performs this capability in your environment, the way you have it configured. Confirmation is what turns a generic catalog entry into an accurate account of your stack.

The distinction matters for two reasons:

• An inferred mapping you never verify may credit you with coverage you do not actually have.

• A capability you removed or never enabled should not stay mapped just because the product can do it.

Treat inferred mappings as a to-do list. Each one is a claim waiting for you to confirm or reject based on how you run the tool.

Working through inferred mappings is some of the highest-value time you can spend in the Map. It sharpens coverage, makes gaps real, and keeps overlap detection honest, since overlap only means something when the mappings underneath it are accurate.

For how mappings come to exist in the first place, see Tool-to-capability mappings.