# Environment map > What is connected, what the agent can actually see and do with it, where it is used, and what is missing. Source: https://triagic.com/checkups/environment-map ## Scope [#scope] Produce the org's data-surface map: every system Triagic can reach, what each one exposes, which work actually uses it, and — most usefully — what the support team clearly depends on that is not connected at all. This is a documentation exercise with findings attached, and it is the right first checkup for a new install. ## Procedure [#procedure] 1. **Inventory what is connected.** Using the connected-server data available to you, list every MCP server for this org: provider, name, whether it is shared at org level or personal to one member, its running state, and its last error if any. Note anything not running — an integration that is configured but broken is a system the team believes it can see and cannot. 2. **Record what each one exposes.** For every reachable server, list the tools actually available to this run and describe in one line what class of data each family covers — "the orders database, read-only, schema and rows", "error events and their stack traces", "cluster and pod state". Note where the tool surface is narrower than the system: a database integration whose role only reads one schema is a much smaller window than its name suggests, and the map should say so. Every listed tool is read-only by construction — writes are filtered out before a run ever sees them — and the map should state that plainly so readers understand what "connected" does and does not authorize. 3. **Confirm identity and scope, not just reachability.** Where a provider offers a cheap read-only identity call (current user, current role, current project/account, list databases or repositories), make it. Reachable is not the same as usefully scoped, and the gap between the account someone intended to connect and the one actually connected is a common surprise. Record the concrete answer: which account, which role, which database or project. 4. **Map the usage.** Check what the support work actually reaches for, using the ticket and investigation history available to you: which systems supply the evidence that resolves tickets. Three groups fall out, and each is a finding shape: * **Connected and used** — the working core. Record it as the baseline. * **Connected and unused** — no investigation touches it. Either it should be put to work or it should be disconnected; either way it is a live credential earning nothing (`credential-hygiene` will price the risk). * **Used but not connected** — this is the valuable one. Look for systems the tickets and investigations *talk about* — a queue, a payment provider, a log store, a CI system — that appear in no integration. Each is a place where a human has to leave Triagic to answer a question, and naming them is the whole point of this map. 5. **Note the shape of the estate.** Which clouds, which databases, which observability stack, which ticket sources feed in. Say where two integrations overlap (two log stores, two metric systems) and where a category is missing entirely — no error tracking, no metrics, no source control. A missing category is a coverage finding even though nothing is broken. 6. **Environment labelling.** Check whether the connected systems make clear which environment they point at. A connection named for its provider rather than its environment ("postgres", "mysql") that actually points at production is a standing hazard: it invites someone to treat a production system as a scratch one. Report it as a naming finding, not a security one. 7. **Write it so a new engineer can read it.** The report is the deliverable here as much as the findings are — someone joining the team should be able to read it and know what this Triagic install can see. ## Finding keys [#finding-keys] The `key` names the *system and the gap*, not this run, so the map's findings close on their own when a system is connected or scoped. Use `::`. * `coverage:payment-provider:not-connected` * `coverage:error-tracking:no-integration-in-category` * `server:clickhouse-analytics:connected-unused` * `server:postgres:environment-unclear` * `scope:snowflake-prod:role-narrower-than-expected` ## Severity rubric [#severity-rubric] Severity is about how badly the gap slows or misleads an investigation. * **critical** — the map is actively misleading: an integration believed to be connected is failing, or a connection points at a different environment than its name implies, so evidence has been read from the wrong place. * **high** — a system that resolved tickets depend on is not connected at all, so every investigation touching it has to leave Triagic; or a whole observability category is missing. * **medium** — a connected integration nothing uses; a connected role scoped far narrower than the team assumes; two overlapping integrations where one is stale. * **low** — naming and labelling problems, minor duplication, a personal-scope connection that ought to be shared at org level. * **info** — the map itself: what is connected, what each exposes, and what work uses it. Recorded so the next run can show what changed. ## Output guidance [#output-guidance] Open with a one-paragraph executive summary a new engineer could read cold: how many systems are connected, what the estate is made of, and the one significant gap. Then: a connected-systems table (System | Provider | Scope or role confirmed | State | Used by), a section per system saying in plain words what it exposes and what an investigation would use it for, a "Connected but unused" section, and a "Used but not connected" section naming the systems the ticket history clearly depends on. Close with a recommendations table (Gap | Recommended action | Why it matters | Effort). State outright that every tool listed is read-only. This report is a document as much as a finding list — write it so it can be handed to someone on their first day.