Environment map

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

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

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 <area>:<system>:<gap-slug>.

• 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 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

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.