How a context resolves, and its fallback rules

A help request names an app and either a key or a path. OpenD tries the key, then its parents, then the app's default, and only ever opens a topic the reader can see.

If the request has a key, that is the requested key, and any path is ignored. Otherwise the most specific route matching the path gives the key. A path that matches no route has no requested key.
The requested key is tried, then each parent: tenants.detail, then tenants.
Then the app's default, and its parents.
For each key, the targets are tried in order, map entries first. A target counts only when all its conditions pass for this reader and its topic is visible to them.
The first target that counts is opened. If none does, there is no help for this context: the panel says so and offers search, and the JSON API answers 404.

The result records how it was found: key (the requested key itself), parent or default. The help lab shows it, and the JSON API returns it as via.

A lookup never reveals a hidden topic

Because hidden targets are skipped, a host app cannot learn about a topic by asking for its key: a reader without the topic simply gets the fallback, exactly as if the key pointed nowhere. The same holds when only part of a key's targets are hidden, which is how one key can open different topics for different releases.

In this site, the opend-console keys for the operator console point at an early-access topic. Readers without the early-access feature fall back to the overview.